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ABSTRACT 


The mission o-f the Branch Clinic, Bancroft Hall, is to 
meet the primary health care needs of the Brigade of 
Midshipmen, U. S. Naval Academy. Equally important, the 
Branch Clinic must monitor the physical qualifications of 
those midshipmen and make recommendations to Naval Academy 
authorities and higher echelon activities regarding their 
suitability to participate in ongoing professional 
development activities and for subsequent service as 
commissioned officers of the Navy and Marine Corps. 

This thesis proposes a microcomputer—based Physiral 
Qualifications Monitoring System for the Branch Clinic. 
Developed as a prototype, the system would provide the 
clinic staff with their first significant hands-on 
a.perience with current information systems technology and 
serve as a basis for a more fully developed microcomputer- 
based system or as a preliminary requirements specification 
for a mainframe-based system. 
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I. 


INTRODUCTION 


The mission of the Branch Clinic, Bancroft Hall, is to 
meet the primary health care needs of the Brigade of 
Midshipmen, U. S. Naval Academy. Equally important, the 
Branch Clinic must monitor the physical qualifications of 
those midshipmen and make recommendations regarding their 
suitability to participate in professional development 
activities and for subsequent service as commissioned 
officers of the Navy and Marine Corps. These 
recommendations are provided to both Naval Academy 
authorities and higher echelon acitivies (e.g.. Naval 
Aerospace Medical Institute, Naval Medical Command, Naval 
Military Personnel Command, Commandant of the Marine Corps). 

To date, the Branch Clinic has monitored physical 
qualifications without data processing support. This thesis 
proposes a microcomputer-based Physical Qualification 
Monitoring System (PQMS) to augment existing manual 
procedures. The system is designed to help the Branch 
Clinic answer inquiries on the physical status of midshipmen 
and in preparing precommissioning physical examinations. 
Developed as a prototype, this system would provide the 
clinic staff with their first significant experience with 
current information systems technology. The proposed PQMS 
could, in turn, serve as the basis for a more fully 











developed microcomputer-based system or as a preliminary 
requirements specification for a mainframe-based system. 

The thesis first describes the organizational context 
and overviews the problem.: These sections are based 
primarily on personal experience as Administrative Officer, 
Branch Clinic, Bancroft Hall, during the period January 1982 
through July 1984, supplemented by telephone conversations 
with the current staff and a site visit during December 
1P85. Next, general characteristics of the POMS proposal 
are examined, including design objectives methodology. The 
system outputs are then discussed, followed by the data 
structures and processing modules. The summary presents the 
proposed hardware/software configuration of the system, 
highlights what PQMS is and is not, and offers some possible 

extensions to underlying concepts. t ■ ' 

c. 

The reader will find that this thesis is more pragmatic 
than theoretic. The information systems concepts are well- 
established in the literature; no new theory or technology 
is required or advocated. Rather these concepts are simply 
brought to bear on a real-life problem which has thus far 
gone unaddressed. Where appropriate, theory is discussed, 
but only to a level consistent with the needs of the reader. 
Every effort is made to focus on the problem, without 
obscuring key issues with unwarranted detail. 







II. ORGANIZATIONAL CONTEXT 


A. MISSION AND ORGANIZATION OF THE U. S. NAVAL ACADEMY 

The mission of the U. S. Naval Academy (USNA) is to 
prepare midshipmen -for service as commissioned officers of 
the Navy and Marine Corps. To accomplish this, particular 
emphasis is placed on the development of a midshipman as a 
whole—academically, professional1y, morally, and 
physically CRef. l:p. 223. The organization of the Naval 
Academy reflects this proven approach. 

The Superintendent has overall responsibility for the 
Naval Academy and its large support complex. His principle 
assistants for the general administration of the Annapolis 
Area complex are his immediate personal staff, the Deputy 
for Operations, and the Deputy for Management. Regarding 
matters specific to the Brigade, the Dean of Admissions, 
Academic Dean, and Commandant of Midshipmen assist the 
Superintendent in the recruitment and subsequent academic 
and professional development of midshipmen. 

Of these, the Commandant of Midshipmen is most directly 
involved with the day-to-day functioning of the Brigade ar ' 
responsible for the uniquely military aspects of midshipmen 
development—prof essional , moral , and physical CRef. l:p. 
241. Several departments under the Commandant assist him 
with this tasl:. The Division of Professional Development 










(PRODEV) conducts ongoing training in professional areas, 
such as leadership, military law, seamanship, and 
navigation. This division also coordinates the summer 
cruise program, providing midshipmen with operational 
experience with fleet and shore-based units of the Navy and 
Marine Corps, and the service selection process by which 
individuals choose the warfare specialty in which thev will 
serve subsequent to graduation. The Brigade Officers and 
Brigade Chaplains share responsibility for the moral 
development of midshipmen through a blend of religious 
activities, leadership, guidance, and personal example. The 
physical development of the Brigade is primarily handled by 
the Physical Education Department, which provides formal 
physical education courses and coordinates an extensive 
intercollegiate and intramural sports program. 

The organization of the Brigade of Midshipmen itself 
also contributes to accomplishment of the Naval Academy 
Ttissicn. The Brigade is divided into six battalions, each 
headed by a senior officer (rank of 0-5 or 0-6) of the Navy 
or Marine Corps. A battalion, in turn, consists of six 
companies, each under command of a Company Officer from the 
Navy or Marine Corps (rank of 0—3 or 0-4). The company is 
the basic organizational unit of the Brigade and consists of 
approx i mately 125 midshipmen. Midshipmen from all four 
classes (or /ear group levels) are assigned to each company. 








B. MISSION AND ORGANIZATION OF THE NAVAL MEDICAL CLINIC AND 

BRANCH CLINIC, BANCROFT HALL 

The Naval Medical Clinic <NMCL), Annapolis, is a tenant 
command of the U. S. Naval Academy, responsible for 
providing general/spedalized outpatient clinic services 
primarily for active duty Navy and Marine Corps personnel, 
midshipmen, and active duty members of other Federal 
Uniformed Services. NMCL Annapolis also provides outpatient 
care to other eligible beneficiaries of the Annapolis Area 
complex (e.g., dependents of active duty personnel, retirees 
and their dependents, etc.) on a space-available basis. 

This activity is organized under a Commanding Officer who 
reports directly to the Commander, Naval Medical Command, 
National Capital Region, Bethesda, Maryland, and to the 
Superintendent, USNA, for additional duty and area 
coordination. CRef. 21 

NMCL Annapolis is physically and functionally divided 
into two distinct units, the Main Clinic and Branch Clinic, 
Bancroft Hall. The Main Clinic is off the main USNA campus 
in the buildings which formerly comprised the Naval Hospital 
Annapolis. In general, this unit consists of the Office of 
the Commanding Officer, all administrative support elements 
of the command, ancillary support services (i.e., Laboratory 
Pharmacy, and Radiology), and those clinical services 
provided primarily for non-active duty benefic 1 ar 1 es, such 
as Primary Care, Pediatrics, and Occupational Health. 
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The Branch Clinic is on the main campus o-f the Naval 
Academy in the basement o-f Bancro-ft Hall, the dormitory 
facility for the Brigade of Midshipmen. This clinic is 
organised under the Senior Medical Officer and corsists of 
several small, but distinct work centers, including Military 
Sick Call, Physical Examinations, Treatment Room, 

Observation Ward, Orthopedics/Sports Medicine, Physical 
Therapy, Optometry, and satellites of the ancillary support 
services at the Main Clinic. The primary beneficiar 1 es of 
the Branch Clinic are the Brigade and the active duty staff 
of the Naval Academy. 

C. NAVAL ACADEMY/BRANCH CLINIC RELATIONSHIP 

The Senior Medical Officer reports directly to the 
Commanding Officer, NMCL Annapolis. Due to the close 
relationship between the Naval Academy and Branch Clinic, 
however, the Senior Medical Officer also has additional duty 
orders to the Superintendent. This relationship has three 
dimensions which parallel the "life cycle" of a midshipman. 

First, the Senior Medical Officer is a member of the 
USNA Admissions Board. Each year this board, chaired bv the 
Superintendent, reviews the qual 1 fications of the 14,000+ 
applicants for admission to the Naval Academy to arrive at a 
plebe (freshman) class of approximately 1300. The Senior 
Medical Officer's role on this board is to establish the 


medical qualif 1 cations of the applicants. 


The principle 













vehicle for that determination is the candidate medical 
examination, conducted under the auspices of the Department 
o-f De-fense Medical Examination Review Board (DODMERB) . An 
interservice agency, DODMERB is responsible -for scheduling 
the medical examinations -for candidates to all service 
academies and ROTC programs and -for making preliminary 
determinations on the medical status of the candidates. 
DODMERB forwards their findings for use by the USNA 
Admissions Board. The Senior Medical Officer advises the 
Beard regarding medical standards and the implications of 
waivering those standards on an individual 's tenure as a 
midshipman and on possible limitations to career prospects 
and duty assignments. 

Second, the Branch Clinic is responsible for maintaining 
the good health of the Brigade of Midshipmen. This is done 
through routine sick call, specialty clinics, immunizations, 
screening tests and examinations, and health education 
programs. When the level of care needed by a midshipman is 
beyond their capabilities, the clinic staff coordinates that 
care with nearby military treatment facilities and, if 
warranted, with civilian facilities. 

Finally, the Branch Clinic monitors the physical 
qualifications of the 4500+ members of the Brigade. This 
task has both short and long term considerations. On the 
short term, the Senior Medical Officer must ensure that 
individuals are medically qualified to perform their duties 
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on a day-to-day basis and to participate in their physically 
demanding professional development activities. From a 
long-term perspective, he must also make recommendations to 
higher authority regarding their suitability to serve as 
commissioned officers of the Navy and Marine Corps following 
graduation. 

It is important to note that although the Senior Medical 
Officer reports to the Superintendent for additional duty, 
he is more directly influenced by and responsible to the 
Commandant of Midshipmen for several reasons. Not only is 
the Commandant invariably a flag officer or flag-selectee, 
but he is also a line officer, whereas the Senior Medical 
Officer is junior (specifically, a Captain) and from a staff 
corps. Both the primary beneficiaries and the building 
containing the Branch Clinic are under control of the 
Commandant. Furthermore, those Naval Academy authorities 
most involved with the daily activities and future careers 
of the Brigade, the Brigade Officers and Division of 
Professional Development, also work for the Commandant. 
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III. PROBLEM STATEMENT/PROPOSED SOLUTION APPROACH 

A. PROBLEM OVERVIEW 

Throughout an individual's -four years as a midshipman, 
much pertinent information is documented in the Health 
Record regarding physical qualifications. Sources include 
the candidate physical examination f or admission into the 
Naval Academy; documentation of routine health care: 
hospitalization and surgery reports; Medical Boards; and 
special purpose screenings, tests, and examinations. 

However, this information has never been fully integrated to 
provide readily accessible physical qualification profiles 
on the Brigade. The only means of obtaining even a 
preliminary indication of a midshipman's physical 
qualification status is to review that individual 's Health 
Record vis-a-vis the physical standards established by 
higher authority. This is a time-consuming process which 
currently must be repeated for each separate inquiry and 
requires detailed knowledge of physical standards by the 
reviewer. When requests are received for information 
involving large segments of the Brigade (e.g., Which 
midshipmen in a given year group are physically qualified 
for duty as Naval Aviators or Naval Flight Officers?), the 
Branch Clinic must manually review all pertinent Health 


Records to respond, often to the exclusion of other work. 





Due to the Health Record layout, this review process can 
lead to important data being overlooked, especially when the 
reviewers are inexperienced. This is o-f particular concern 
since the Branch Clinic must augment its staff with health 
care providers from other naval medical facilities and Naval 
Reserve units to complete the annual precommissioning 
physical examination evolution. Although these providers 
are competent in their own right, they are often unfamiliar 
with current standards and the exacting requirements of 
these physical examinations and are apt to overlook critical 
data in the Health Record. 


B. PROPOSAL 

Given the volume of queries and physical examinations 
handled by the Branch Clinic each year, the need exists for 
current, easily retrievable physical qualification profiles 
on all midshipmen. This thesis proposes a microcomputer- 
based Physical Qualification Monitoring System (PQMS) to 
meet that need. With such a capability, the Branch Clinic 
would be more responsive to inquiries from Naval Academy 
authorities regarding the physical qualifications of 
midshipmen. Additionally, the accuracy of precommissioning 
physical examinations generated by the Branch Clinic would 
be enhanced, so that midshipmen are recommended for only 
those warfare specialties they are physically qualified for. 














C. SECONDARY DESIGN OBJECTIVES 

Several secondary objectives motivated the design of the 
prototype Physical Qualifications Monitoring System. The 
most important of these are presented below in their 
approximate order of importance: 

1. Minimize the risk exposure of the Branch Clinic. 

At least three factors affect the degree of risk in 
any information systems project CRef. 3:pp. 313-314]: 

- Project size (the 1arger the project, the greater the 
risk) , 

- Experience with the technology to be employed (the 
greater the prior experience, the lesser the risk—and 
vice versa), and 

- Project structure (the more well-defined and fixed the 
system outputs, the lesser the risk). 

Clearly, all risk cannot be avoided. This is especially 

true in this instance with regard to experience with the 

technology. 

Nolan has identified four phases of organizational 
learning relevant to information systems technology. These 
range from identifying a technology of potential value to an 
organization and undertaking a pilot project (Phase 1) to 
widespread technology diffusion where experience in one 
branch of an organization is easily transferred to other 
branches (Phase IV). CRef. 3:p. 301 The only known 
automated data processing experience of the Branch Clinic is 
the use of punched cards for immunization evolutions and the 
casual use by a limited number of staff of the Brigade 















Roster System on the Naval Academy Time-Sharing System to 
generate rosters of midshipmen. 

According to Nolan's scheme, then, the clinic is clearly 
at the beginning of Phase I, where the risks to an 
organization are inherently higher. To counteract this, 
emphasis focused on the other two risk factors. The outputs 
of the system were identified early and fixed in both form 
and content. By keeping these outputs to the minimum needed 
to evaluate the PQMS prototype and meet the reporting needs 
of the Branch Clinic, the project was also kept to a 
manageable size. 

2. Minimize the time investment to learn and to use the 

prototype. 

Key to the acceptance of any system is that the 
users be able to learn and use the system quickly. To 
achieve this, the FQMS Users' Manual is less than 40 pages 
long and provides step-by-step instructions for all 
processing modules, including very detailed explanation of 
those off-line procedures involving the Naval Academy 
Time-Sharing System. The system is itself menu-driven so 
that the user need not understand the underlying programs 
and programming language. Personal data (e.g., name. Social 
Security number, date of birth, etc.) is downloaded from 
existing Naval Academy files so that this data does not have 
to be rekeyed or maintained by the Branch Clinic staff. 















Provide mechanisms for data security. 


Although PQMS is a prototype, the system stores 
personal data covered by the Privacy Act of 1974 and 
sensitive medical information. Security against 
unauthorized access, therefore, is a prime concern, so 
appropriate safeguards are part of the design. Users must 
enter a password to log onto the system, and the password 
can be easily changed once successfully logged on. Privacy 
Act Warning statements are displayed on entering and exitinq 
the program. Two types of reports are provided, detailed 
reports for use within the Branch Clinic and summary reports 
for distribution outside the clinic. 

4. Provide a repository for current physical standards 
information. 

Continuity is a problem at any military activity due 
to the frequent rotation of personnel. The Branch Clinic is 
no exception, with a new Senior Medical Officer and Head, 
Physical Examinations Department, reporting aboard every few 
/ears. Therefore, the POMS was designed to store detailed 
physical standards information which would be preserved 
despite staff changes. 


D. DESIGN METHODOLOGY 

To facilitate development of the PQMS, considerable 
thought was devoted to which of two common design 


methodologies to use: i) data flow-oriented, ii) data 

structure-oriented. The farmer, data f1ow—or 1 ented design, 














considers in-formation as a continuous '••flow 1 ' -from input 


through a series o-f transforms (processes) to output. This 
data flow is mapped to provide a representation of software 
structure. CRef. 4:pp. 17S-1791 

Although data flow-oriented design can be used for a 
broad range of applications and is probably more widely 
documented in the literature, a data structure-oriented 
design approach was chosen for PQMS. This was primarily due 
to the well-defined structure of the inputs, data base 
files, and outputs of the system. Data structure-oriented 
design proposes that where such well-defined structures 
exist, they can be used as the basis for software 
development. Rather than considering data flows and data 
flow diagrams, this approach transforms representations of 
data structure into representations of software structure. 
The procedural aspects of processing modules are essentially 
a by-product of data structure. CRef. 4:pp. 205-2071 
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IV. PQMS OUTPUTS 


The intent of the Physical Qualifications Monitoring 
System is to provide current, easily retrievable physical 
qualification profiles on all Naval Academy midshipmen. The 
form and content of these profiles, in turn, are based on 
the information needs of both the direct users (the Branch 
Clinic staff) and indirect users (all others to whom 
information from the system is provided). 

POMS provides information at two levels of detail. To 
answer inquiries on specific midshipmen and to facilitate 
the annual precommissioning physical examination evolution, 
detailed reports are needed. These show not only an 
individual's physical qualification status by warfare 
specialty, but also the disqualifying conditions, standards, 
and waivers which underlie those determinations. To answer 
inquiries from outside the clinic on organisational segments 
of the Brigade, such as a company or year group, summary 
reports which show physical qualification status by warfare 
specialty are adequate. The next two sections discuss the 
specific format and content of these detailed and summary 
reports. 


A. DETAILED REPORTS 

Figure 1 shows the general format of the detailed 
reports produced by PQMS. 


Ift 
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Naae: MCGIFFIN PHILO Alpha: 891234 Zo*i 09 

3SN: 123456789 Sex: M DOB: 620727 

Code Disqualifier Date AIR NFO OPS WAR SUB NUC URL NC RL 

XXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XX/XX/XX XX XX XX XX XX XX XX XX XX 


SuMary: XX XX XX XX XX XX XX XX XX 

CoMents: 

XX/XX/XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


Figure 1. Detailed Physical Qualification Status Report 

I 

The heading data on this report is self-explanatory, except 
for "Alpha:." The alpha number is a numeric identifier 

assigned to each midshipman on entry into the Naval Academy | 

and is the key for most records maintained by the Naval 
Academy. It is formed by concatenat i ng the last two digits 
of midshipman's year group with a four-digit number j 

representing the alphabetized position of that person's name 
within the Brigade. 

The ne;;t section of the report is a detailed and 
summarized listing of physical qualification status 
information. For each disqualifying condition recorded for 


a midshipman, a text description and date stamp (reflecting 












how current that entry is) is shown. In addition, a set of 
"flags" reflects the impact of that disqualifier on the 
midshipman's eligibility for the various warfare 
specialties. The column headers for these flags represent 
the following specialty groups: 


AIR 

— Naval Aviator 

NUC 

- Surface Nuclear 

NFQ 

- Naval Flight Officer 

URL 

- Unrestricted Line 

OPS 

- Special Operations 

MC 

— Marine Corps 

WAR 

- Special Warfare 

RL 

- Restricted Line/ 


Staff Corps 


SUB - Submarine Duty 

The flags themselves can assume one of the following values: 

PQ - physically qualified 

WG - not physically qualified/waiver granted by higher 
authority 

LW - not physically qualified/1imi ted waiver granted by 
higher authority 

WR - not physically qualified/waiver requested from higher 
authority 

UE - undergoing evaluation/status indeterminate at this 
1 1 me 

NO - not qualified 

The summary flags show the overall impact of the individual 
flags on a midshipman's physical qualification status for 
each warfare specialty. 

The final section of the detailed report displays 
free-te::t comments. These are limited to 60 characters 
each, date stamped, and provide information specific to a 
midshipman which the ROMS cannot otherwise store. 






The detailed report format is generic and can be 
generated three different ways. First, a single report can 
be displayed on the CRT screen of the microcomputer. 

Because of the BO x 25 character size limitation of a CRT, 
the report is split into two screens, one containing the 
header and disqualifier information and the other containing 
any comments. Second, the user can direct the output to an 
attached printer, producing a single-sheet report. Finally, 
a series of detailed reports on all midshipmen in a given 
company and year group can be directed to the printer. This 
option is primarily intended to facilitate the annual 
precommissioning physical examination process by providing 
reports in the same logical unit that the examinations are 
processed. 

B. SUMMARY REPORTS 

Figure 2 shows the general format of the summary reports 
produced by PQMS. 

Given the discussion of the prior section, the contents 
of this report need no additional explanation. The report 
simply shows physical qualification summaries for whichever 
of two categories of midshipmen is chosen, either a year 
group sorted by company or a company sorted by year group. 

In both cases, each distinct subgroup (company or year 
group, respectively) is listed on a separate sheet of paper. 



























BRANCH CLINIC, BANCROFT HALL 
ANNAPOLIS, MD 21402 

DISQUALIFICATION CODES 

CODE DISQUALIFY DATE AIR IFO OPS WAR SUB NUC URL HC RL 

XXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XX/XX/XX XX XX XX XX XX XX XX XX XX 


Figure 3. Disqualification Codes Report 

descriptions to memory. In addition, the listings can be 
distributed outside the Branch Clinic, either as a reference 
guide for the indirect PQMS users or for validation of the 
standards data by higher authority (e.g.. Naval Aerospace 


Medical Institute or Naval Medical Command) 
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V. DATA STRUCTURES 

The data structures o-f the Physical Qualifications 
Monitoring System provide the basis for the outputs and 
processing modules of the system. These structures are 
based on the relational data base model and implemented 
using the popular microcomputer product, dBASE III. This 
chapter provides a brief overview of this model and then a 
detailed discussion of the five PQMS data base files: 
BRIGADE, STANDARDS, DISQUALIFIERS, COMMENTS, and SUMMARY. 

A. OVERVIEW OF RELATIONAL DATA BASE MODEL 

The relational model uses two-dimensional tables to 

represent data. These tables (or relations) have several 

important properties. Each entry in the table can contain 

only a single-value; repeating groups or arrays cannot be 

used as entries. Each column has a unique name and is 

called an attribute or field. All entries within a column 

are of the same type and come from the same domain of 

permissible values. The rows of the relation are the 

individual records of the data base file. No two rows in 

the table may be identical, and each row is identified by a 

unique key farmed by some attribute or combination of 

attributes from the relation. The relational model not only 

requires each record to have a primary key, but also permits 

* 

alternate keys if they too are unique. CRef. 5:pp. 243-2451 
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As is the case with the PQMS, a data base usually 
consists of several different relations or tables. Key 
questions are then: What kinds of relationships can exist 
among the tables and how are they represented? There are 
three basic types of relationships. A tree, also known as a 
hierarchy, consists of a collection of records and 
one-to-many relationships among records. Each record can 
have one and only one parent. A simple network relaxes this 
definition slightly, so that a record can have more than one 
parent so long as they are of different types. Lastly, a 
complex network consists of a collection of records and 
many-to-many relationships (i.e., records may have multiple 
parents including some which are of the same type). CRef. 
5:p. 117-1223 As illustrated later in this chapter, PQMS 
uses both the tree (between the BRIGADE and COMMENTS data 
base files) and complex network (between the BRIGADE and 
STANDARDS data base files). 

Just as different types of relationships may exist among 
relations, so too can the relationships be represented in 
various ways. The relational model is noteworthy in that 
the table entries themselves identify any relationships, 
rather than requiring them to be explicitly defined when the 
logical format of the data base is first specified. The 
table entries typically used for this purpose are the record 
keys (or portions of them), although this is not always 
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true. Relationships among the PQMS data base tiles are 


defined exclusively by record keys. 


B. BRIGADE DATA BASE FILE 


The BRIGADE data base tile contains personal, 
non-medical data on each midshipman. Figure 4 describes 
this file. The data elements are a subset of those 
contained in the Brigade Raster File (BROSTER), a well- 
established data base maintained by the Midshipman Personnel 
Office. The procedural aspects of downloading this data to 
the PQMS microcomputer are given in the next chapter. 

Two keys are used for BRIGADE, Alpha and SSN. Both are 
unique and allow the user more flexibility in querying PQMS. 
In addition, the file is indexed (i.e., sorted) on three 
different fields, Alpha, SSN, and the concatenation of 
Company+Alpha, to accelerate search routines and overal1 
program execution, as well as to properly sequence printed 
outputs. 


C. STANDARDS DATA BASE FILE 

Figure 5 describes the STANDARDS data base file. In 
essence, this file is the Branch Clinic's corporate memory 
of the physical standards contained in the Manual of the 
Medical Department and other pertinent directives. Each 
record in STANDARDS includes a unique code established by 
the Branch Clinic, a text description of the disqualifying 
condition, and a series of nine flags which reflect the 











Data Base File: BRIGADE 


Description: Personal, non-medical data on each midshipman 

Data Elements: 


Field Name 

Type 

Length 

Remarks: 

Alpha 

Char 

6 

The first two digits of the alpha number 


are the last two digits of the year 
in which the midshipman will graduate. 
The regaining -four digits are reflect 
the alphabetized position of the 
midshipman's name within the Brigade, 
without regard to /ear of graduation. 

EXAMPLE: 391234 


SSN 

Char 

o 

Social Security Number of midshipman, 
non-hyphenated. 

EXAMPLE: 123456789 

Last 

Char 

20 

Last name of midshipman, in all capital 
letters and padded with blanks to the 
right as necessary. 

EXAMPLE: MC6IFFIN 

First 

Char 

15 

f rst name of midshipman, in all capital 
letters and padded with blanks to the 
right as necessary. 

EXAMPLE: PHILO 

Sex 

Char 

1 

Sex of midshipman, N (male) or F (female* 
EXAMPLE: M 

DOB 

Char 

6 

Midshipman s date of birth, YVMMDD format 
EXAMPLE: 620727 

Company 

Char 

2 

Company to which midshipman is assigned, 


expressed as two digits (01,...,36'. 
EXAMPLE: 09 

Primary Key: Alpha 
Alternate Key: SSN 

Indexes: Alpha, SSN, Cotpany+Alpha 













Data Base File: STANDARDS 


Description: 


Physical standards fro* the Manual of the Medical Department and 
other pertinent directives 


Data Elements: 


Field Name 


Code 


Type Length Remarks : 

Char 5 Alphanumeric code based on International 

Classification of Diseases, 9th Edition, 
Clinical Modification, which uniquely 
identifies the disquaiifyina condition. 
EXAMPLE: 36850 


Text 


Char 


Text description of the disqualifying 
condition, using generally accepted 
medical terminology and abbreviations 
as needed to restrict the description 
to 25 characters or less. 

EXAMPLE: COLOR VISION DEFICIENCY 


AIR std 


Char 


Flag which indicates whether the disqual¬ 
ifying condition would render a 
midshipman physically qualified (PQ> 
or not physically qualified (NQ) for 
duty as a student naval aviator. 

EXAMPLE: NQ 


NFOstd 

Char 


* SAA, except student naval flight officer 

0PS%td 

Char 

O 

L. 

SAA, except special operations duty. 

HAR^std 

Char 

0 

L. 

SAA, except special warfare duty. 

SUB'std 

Char 

0 

SAA, except submarine duty. 

NUc'std 

Char 

n 

SAA, except surface nuclear duty. 

UPt_std 

Char 

"i 

SAA, except unrestricted line. 

MC.std 

Char 

Hi 

SAA, except U. S. Marine Corps. 

RL'std 

Char 

r> 

SAA, except restricted line;staff corps. 

Date 

Date 

8 

Date of most recent update to standard. 


MN/OD/YY format. 
EXAMPLE: 03/27/86 


Primary Key: Code 
Indexes: Cede, Text 


* SAA - Same as above 


Figure 


Description of STANDARDS Data Base File 
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impact o-f that condition on a midshipman's physical 
qualification -for the various war-fare specialties. The 
record also carries a date stamp showing when the entry was 
most recently updated. The key -for STANDARDS is the Code 
-field, and the file is indexed on both the Code and Text 
f i el ds. 

Some attributes o-f the STANDARD data base -file warrant 
further elaboration. The Code field has been designed to 
accommodate the coding scheme of the International 
Classification of Diseases, 9th Revision, Clinical 
Modification (ICD—9—CM). Basically, ICD—9—CM categorizes 
diseases and injuries and assigns a five-digit code to each. 
The first three digits identify the system of the body 
affected; the last two digits add the necessary detail to 
identify the specific disease or injury. Figure 6 shows the 
major classifications of ICD-9-CM and their three-digit 
rubrics. [Ref. 63 

The ICD-9-CM coding scheme was chosen for two reasons. 
First, ICD-9-CM is used throughout the Navy to classify 
morbidity and mortality information for statistical reports 
and to index medical treatment records by disease or injury. 
Therefore, the coding scheme is a familiar one and 
eliminates the need to develop a scheme unique to PQMS. 
Second, DODMERB is currently developing a new dictionary of 
disqualification codes based on ICD-9-CM, which the Branch 
Clinic could adapt to meet their own needs. This would both 














Code Series 


Classification 


00100 - 13999 

Infectious and Parasitic Diseases 

14000 - 23999 

Neoplasms 

24000 - 27999 

Endocrine, Nutritional, and Metabolic Diseases 
and Immunity Disorders 

28000 - 28999 

Diseases of the Blood and Blood-forming Organs 

29000 - 31999 

Mental Disorders 

32000 - 38999 

Diseases of the Nervous System and Sense Organs 

39000 - 45999 

Diseases of the Circulatory System 

46000 - 51999 

Diseases of the Respiratory System 

52000 - 57999 

Diseases of the Digestive System 

58000 - 62999 

Diseases of the Genitourinary System 

43000 - 67499 

Complications of Pregnancy, Childbirth, and the 
Puerpenum 

48000 - 7i)999 

Diseases of the Skin and Subcutaneous Tissue 

71000 - 73999 

Diseases of the Musculoskeletal System and 
Connective Tissue 

74000 - 75999 

Congenital Anomalies 

76000 - 77999 

Certain Conditions Originating in the Perinatal 
Period 

78000 - 79999 

Symptoms, Signs, and Ill-Defined Conditions 

30000 - 99999 

Injury and Poisoning 


SOURCE: International Classification of Oiseases, 9th Edition, 
Clinical Modification, Commission on Professional and 
Hospital Activities, Ann Arbor, Michigan, March 1990. 


Figure 6. Classification of Diseases and Injuries 


enhance consistency among these related systems and 
facilitate the recording of medical problems identified by 
DODMERB on the candidate medical examination into the PQMS 
data base. 

The domain of the flag fields in the STANDARDS data base 
file consists of only two possible values: PQ (physically 


qualified) or NO (not physically qualified). At first, this 







may seem unduly restrictive, since it implies that standards 
are absolute and disregard individual circumstances. 
Actually, these values are merely endpoints on a continuum 
and provide a -first-cut determination o-f an individual's 
physical qualification status. As discussed in the next 
section, these -flags can be modified by those of the 
DISQUALIFIERS data base file to reflect specific situations, 
such as not physically qualified/waiver granted, not 
physically qualified/waiver requested, etc. 

D. DISQUALIFIERS DATA BASE FILE 

A complex relationship exists between the BRIGADE and 

STANDARDS data base files. This means that each midshipman 

record can be related to many standards (i.e., a midshipman 

can have more than one disqualifying condition) and each 

standard can be related to many midshipmen (i.e., more than 

one midshipman can have a certain disqualifying condition). 

This many-to-many relationship can be illustrated as: 

+- 1 - +-+ 

: brigade :<<->>: standards : 

+ - + - +• 

Note the two-headed arrows pointing in both directions, 

indicative of a complex relationship. 

Complex relationships are awkward to implement, so the 

relational model decomposes such relationships using an 

intersection record. As the name implies, this record 

represents the merger, or "intersection," of two other 













records CRef. 5:p. 1453. PQMS uses the DISQUALIFIERS data 
base -file for this purpose. 


The resulting simple network can be represented as: 

+ - ► ^ - +• + - + 

: brigade :<->>: disqualifiers :<<->: standards : 

+ - + +-+ + - + 

Note that the two resulting relationships are one—to—many, 

denoted by single-headed arrows pointing toward BRIGADE and 

STANDARDS. This means that each record in DISQUALIFIERS can 

have only one parent in BRIGADE and one in STANDARDS. 

Figure 7 describes the DISQUALIFIERS data base file. 

This file contains a unique record for each instance where a 
midshipman is identified to have a disqualifying condition. 
The key for these intersection records is the combination of 
the midshipman's alpha number and code assigned to the 
disqualifying condition (i.e. , Alpha+Code). Each record 
also has a series of flags corresponding to the nine warfare 
specialty categories. These are the flags which relax the 
rigid PQ/NQ flags of the STANDARDS file. For each warfare 
specialty, the flags from STANDARDS and DISQUALIFIERS are 
compared. If the STANDARDS flag is PQ, the condition is not 
disqualifying for that particular warfare specialty, so the 
DISQUALIFIERS flag is irrelevant and the resulting status 
flag is PQ. However, if the STANDARDS flag is NQ, it could 
be modified by any DISQUALIFIERS flag. If the corresponding 
DISQUALIFIERS flag is WG, LW, or WR the resulting status 
flag would also be WG, LW, or WR, respectively. If the 

















Data Base File: DISQUALIFIED 

Description: Intersection File which decomposes the complex relationship 

between BRIGADE and STANDARDS into a simple network. 

Data Elements: 


Field Name 

Type 

Lenqth 

Alpha 

Char 

b 

Code 

Char 

' 5 

AIR waiver 

Char 

L 


NFOwaiver 

Char 


OPS_waiver 

Char 

L 

MAR_waiver 

Char 

<"* 

3U8_waiver 

Char 

L. 

NUC^waiver 

Char 

n 

UPL_waiver 

Char 

<■» 

L 

MCjtai ver 

Char 

a 

RL_waiver 

Char 

"i 

L 

Date 

Date 

a 


Primary key: Alpha+Code 
Indexes: Alpha, Code 


Remarks : 

Alpha number oF the midshipman to whom 
the disqualiFier is assigned. 

Code oF the disqualiFymq condition 
assigned to the given midshipman. 

Flag which may modiFy the corresponding 
Flag From the STANDARDS data base file 
For duty as a student naval aviator 
(i.e., AIR_std). 

Permissible values include: 

W6 - not physically qualified/waiver 
granted 

LM - not physically qualiFied/hmited 
waiver granted 

MR - not physically qualiFied/waiver 
requested 

UE - undergoing evaiuation/status 
indeterminate at this time 
IF none oF the Foregoing Flags apply, 
the Field is leFt blank. 

* SAA, except student naval Flight oFFicer. 
3AA, except special operations duty. 

SAA, except special warFare duty. 

SAA, except submarine duty. 

SAA, except surFace nuclear duty. 

SAA, except unrestricted line. 

SAA, except U. 5. Marine Corps. 

SAA, except restricted line/staff corps. 

Date oF most recent update to entry, 
MM/DD/VY Fermat. 

* SAA - Same as above 


Figure 7. Description of DISQUALIFIERS Data Base File 
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DISQUALIFIERS flag is blank, there is no modification, and 
the status flag would be NQ. The only exception to this 
scheme occurs when the DISQUALIFIERS flag is UE (undergoing 
evaluation). This means that regardless of what the 
STANDARDS flag specifies, the midshipman's status is 
indeterminate at that time, so the resulting status flag 
would be UE. Figure 8 shows the decision table for this 
process. 


If the STANDARDS flag for a 
warfare specialty is: 


PQ NQ NQ NQ NQ PQ or NQ 


And the corresponding DISQUALIFIERS 
flag is: 


UE WG LW MR UE 


Then the status flag for that 
warfare specialty is: 


PQ WG LW WR NQ UE 


Key : UE - not UE (i.e., WG, LW, NR, or blanki 
.. - blank 


Figure 8. Decision Table for STANDARDS—DISQUALIFIERS Flag 

The algorithm for determining a midshipman s overall 
physical qualification status is slightly different. 

First, the nine status flags for each disqualifying 
condition are determined as described in the preceding 
paragraph. These status flags are then compared within eac 
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warfare specialty. If any single status flag is NQ, the 
midshipman is not physically qualified for that warfare 
specialty, and the summary flag evaluates to NQ. 

Similarly, if no status flags are NQ but at least one is 
UE, the midshipman's status is indeterminate, and the 
summary flag evaluates to UE. This process continues in 
like manner for the WR, LW, and WG flag values. A 
summary flag evaluates to PQ (physically qualified) if and 
only if all status flags for the particular warfare 
specialty are also PQ. Of course, if a midshipman has no 
disqualifying conditions, then all summary flags evaluate to 
PQ. Figure 9 illustrates this algorithm. 


IF (any status flag for a warfare specialty = NQ) 

THEN (summary flag = NQ) 

ELSE IF (any status flag for that warfare specialty 
THEN (summary flag = UE) 

END IF 

ELSE IF (any status flag for that warfare specialty = 
THEN (summary flag = WR) 

END IF 

ELSE IF (any status flag for that warfare specialty = 
THEN (summary flag = LW) 

END IF 

ELSE IF (any status flag for that warfare specialty = 
THEN (summary flag = WG) 

ENDIF 


ELSE (summary flag = PQ) 
ENDIF 
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Note that because the summary flags are dependent upon 
the STANDARDS and DISQUALIFIERS flags and therefore subject 
to relatively frequent change, they are not part of the 
permanent PQMS data base. Instead, the summary flags are 
reevaluated each time a detailed or summary report is 
generated and either immediately displayed to the CRT screen 
or printer or stored to a temporary data structure as 
described later. 

Finally, in addition to the Alpha, Code, and nine flag 
fields, each DISQUALIFIERS record has a date stamp which 
shows how current the data in the record is. As mentioned 
before, the key is Alpha+Code, and the file is indexed 
on both the Alpha and Code fields. 

E. COMMENTS DATA BASE FILE 

Although the BRIGADE, STANDARDS, and DISQUALIFIERS data 
base files provide a detailed profile of the physical 
qualification status of each midshipmen, they do not handle 
all contingencies. Therefore, PQMS also has a COMMENTS data 
base file which stores information which cannot be otherwise 
entered into the system. Figure 10 describes this file. 

The Alpha field establishes the tree relationship 
between BRIGADE and COMMENTS; each record in COMMENTS has 
one and only one parent record in BRIGADE. The Comment 
field may contain whatever information the user feels is 
needed to clarify the midshipman's physical qualification 













Data Base File: COMMENTS 


Description: Information impacting on physical qualification status which 

cannot otherwise be stored by PB1S. 


Data Elements: 




Field Name 

Type 

Length 

Remarks: 

Alpha 

Char 

6 

Alpha number of the midshipman to whom 
the comment applies. 

EXAMPLE: 891234 

Comment 

Char 

60 

Comment entered as free text. 

EXAMPLE: ACL REPAIR SCHEDULED 27JUL36 

Date 

Date 

S 

Date comment was entered into data bas< 
MM/DD/YY format. 

EXAMPLE: 07/13/86 


1 Primary Key: Alpha (nonunique) 

f 

i 

1 Index: Alpha+Date 

l 

Figure 10. Description of COMMENTS Data Base File 

status, and the date stamp shows when the comment was 
recorded. No unique key is explicitly defined for COMMENTS 
but Alpha serves adequately as nonunique key. The file is 
indexed on the combined Alpha+Date fields. 

F. SUMMARY DATA BASE FILE 

The SUMMARY data base file, described in Figure 11, is 
actually a temporary structure. When a detailed physical 
qualification status report is generated (see Figure 1), 
SUMMARY provides a scratchpad for storing intermediate and 
final results of the summary flags algorithm of Figure 9. 







Data Base File: SUMMARY 


Description: Temporary data base file which stores personal data and summary 

flags for detailed or summary physical qualification reports 


Data Elements: 




Field Name 

Type 

Length 

Remarks: 

Alpha 

Char 

6 

Alpha number of the midshipman. 

Name 

Char 

25 

Last and first names of the midshipman, 
separated by a comma and truncated. 
EXAMPLE: MCGIFFIN, PHILO 

Company 

Char 

n 

i. 

Company to which midshipman is assiqned. 

AIR_f1ag 

Char 

2 

Summary flag which indicates midshipman s 
physical qualification for duty as a 


a student naval aviator. 

Permissible values include: 

PQ - physically qualified 

MG - not physically qualified/war/er 
granted 

LW - not physically qualified/limited 
waiver granted 

WR - not physically qualified/waiver 
requested 

UE - undergoing evaluation/status 
indeterminate at this time 

NQ - not physically qualified 


NFOflag 

Char 

2 

» SAA, except student naval flight officer 

OPS.flag 

Char 

n 

SAA, except special operations duty. 

WARf 1 pig 

Char 

a 

SAA, except special warfare duty. 

5UB_flag 

Char 

n 

SAA, except submarine duty. 

NUC.flaq 

Char 

n 

SAA, except surface nuclear duty. 

URL_flag 

Char 

a 

SAA, except unrestricted line. 

MC.flaq 

Char 

n 

SAA, except U. S. Marine Corps. 

RL_flag 

Char 

n 

SAA, except restricted line/staff corps. 


Primary Key: Alpha * SAA - Same as above 

Index: Alpha or Company+Alpha (depending on report being generated) 















When a summary reports are generated (see Figure 2), SUMMARY 
stores personal data -from the BRIGADE file, as well as the 
results of the summary flag algorithm. In either case, the 
contents of SUMMARY are erased after the report is produced, 
leaving only a superstructure which can be reused for the 
next detailed or summary report. 

The Name field in the SUMMARY file is a combination of 
the midshipman's last and first names, truncated to 25 
characters to allow use of the built-in dBASE III report 
generator for summary reports. The other fields are 
self-explanatory. The key for SUMMARY is the Alpha field. 
When summary reports are generated, indexes are created "on 
the fly" based on either the Alpha or Company+Alpha fields, 
depending on the desired sort sequence. These indexes are 
also temporary and erased after the reports are printed. 












Consistent with the data structure-oriented design 


approach, the PQMS data base files provide the basis for the 
procedural aspects of the system. In general, a hierarchy 
of modules exists as illustrated at a first level of detail 



Figure 12. Hierarchy of PQIiS Modules 


The system is menu-driven, so no knowledge of the underlying 
dBASE III language or programs is needed to effectively 
interact with PQMS. Visual and auditory prompts guide the 
user through all facets of the program, and extensive error¬ 


trapping validates inputs and maintains the integrity of the 















data bases. The following sections overview the PQMS 
principles of operation. 

A. ENTERING AND EXITING PQMS 

To begin using PQMS, the user must first enter a 
password. (The user gets three attempts at this, after 
which processing is aborted and control returned to the 
microcomputer's operating system.) After a successful 
logon, the user gets an opportunity to change the current 
password, an action strongly encouraged_from time to time to 
prevent unauthorised access to the system. An introductory 
banner is displayed, followed by a Privacy Act Warning. 

POMS then presents its main menu from which the user invokes 
the subordinate processing modules. When the user decides to 
exit PQMS, the Privacy Act Warning is again displayed before 
control reverts to the operating system. 

B. UPDATING PERSONAL DATA 

There are actually two phases to updating the personal 
data in the BRIGADE data base file. The first is an 
off-line process involving the Naval Academy Time-Sharing 
System (NATS) and the Brigade Roster File (BROSTER). 

Running a NATS program called BRIGREAD**-*, the user creates 
a file containing the alpha number. Social Security number, 
last name, first name, sex, date of birth, and company of 
every member of the Brigade. This file is then downloaded 
from the NATS Honeywell DPS 3 computer through a 2400-baud, 












hard-wired line to the Branch Clinic microcomputer, using 


the KERMIT communication protocol on both computers to 
ensure reliable, error-checked data transfer. 

When this data is on the hard disk storage unit of the 
microcomputer, POMS can update the BRIGADE data base as 
follows. After ensuring that the new file of personal data 
is in place, POMS erases the old BRIGADE data base and its 
indexes, creates an empty data structure of the appropriate 
format, appends to that structure from the downloaded file, 
and reindexes the new BRIGADE data base. PQMS deletes then 
records in the DISOUALIFIERS and COMMENTS files which no 
longer have a counterpart in BRIGADE, and control reverts to 
the main menu. 

This process is unlike others in POMS in that it tafes 
place in batch mode and only periodically, rather than 
on-line and continuously as is typical of the other updates. 
This raises a question as to whether the overall performance 
of POMS suffers due to the BRIGADE data being outdated. 

This is not the case at all! Martin has identified five 
classes of data according to increasing complexity of 
update CRef. 7:pp. 281-2843: 

Class 0 - Unchanging data 

Class 1 - Data which are updated by simple replacement 

Class 2 - Data with independent nonrepeatable updates 


Class 3 - Data with time-critical updates 

Class 4 - Data for which an update may trigger an action 
in a different machine 














The data element of BRIGADE most susceptible to change is 
Company, which is known to change at the end o-f the fourth 
class (freshman) year and on some other rare occasions. All 
other data elements are unchanging, except for correction of 
erroneous initial entries. Therefore, the overall 
classification for BRIGADE is Class 1, in which case the 
replacement scheme used by PQMS is quite appropriate. 
Additional benefits are that the Branch Clinic does not have 
to replicate the substantial efforts of the Midshipman 
Personnel Office by initially entering or maintaining the 
data and that consistency between BROSTER and PQMS is 
assured. 

C. UPDATING STANDARDS DATA 

Updating the STANDARDS data base file involves three 
activities: adding, modifying, and deleting standards. When 
adding to the data base, the user first enters the code for 
the new standard. The entry is checked to ensure that it is 
five characters long and than the code has not already been 
used for any existing standard; the user is reprompted if 
the code fails either test. If the code is valid, a blank 
record is appended to STANDARDS, and the user enters a text 
description for the disqualifier and the standard flags for 
the nine warfare specialties <i.e., AIR_std, NFO_std, etc.). 
Each flag is validated as PQ or NQ before proceeding to the 
next. Before storing and indexing the new record, PQMS 












displays all input and asks for confirmation. Based on the 
user's response, the data is either committed to the data 
base along with the current date or cleared -from memory. 

To modify a standard, the user first enters its five¬ 
digit code. If the code does not exist, an error message 
results. Otherwise, PQMS displays the code, text 
description, and flags for the standard. After confirming 
that this is the desired record, the user enters a new 
series of flags, which are also validated as being PQ or NQ. 
As before, the user must confirm that the new data is to be 
committed to the data base, at which point the Date field of 
the record is changed as well. 

When attempting to delete a standard, PQMS first checks 
to see if the code which the user entered exists. If not, 
an error message results. If it does, the DISQUALIFTERS 
files is searched to see if any intersection records exist 
for that code. To maintain data base integrity, PQMS will 
not delete a standard which has any associated intersection 
records. Assuming this is not the case, the code, text 
description, and flags for the standard are displayed. The 
record is deleted only after approval by the user. 

Access to any of these three processes is through the 
Update_STANDARDS module. Once a subordinate module is 
entered, the add, modify, or delete cycle continues until a 
null ('blank) is entered at the code prompt. Control then 
reverts back to the superordinate, Update STANDARDS module. 









D. UPDATING DISQUALIFIERS DATA 

Updating the DISQUALIFIERS data base -file is similar in 
several respects to updating STANDARDS. Options include 
adding, modifying, and deleting disqualifiers. Access to 
these is through the Update_DISQUALIFIERS menu, and after 
entering any of the subordinate modules, processing loops 
within that module until the user responds to the prompt for 
an alpha or Social Security number with a null value. On 
the other hand, updating DISQUALIFIERS requires some 
additional steps due to the inherent complexity of 
intersection records. 

Adding to the DISQUALIFIERS file begins by inputting 
either the alpha or Social Security number of the midshipman 
to whom the new disqualifier will be assigned. This 
flexibility is built into PQMS because Naval Academy 
authorities typically identify midshipmen by alpha number, 
whereas the Branch Clinic uses Social Security number almost 
exclusively to identify Health Records, physical 
examinations, and the like. Assuming the length of the 
value provided is valid <i.e., 6 or 9 characters), PQMS 
chooses either the Alpha or 3SN index and searches for the 
input value. If it is not found, an error message results, 
reprompting the user for a valid key. Otherwise, PQMS 
displays the midshipman's full name and company number and 
asks for confirmation that this is the desired individual. 
The user then enters the code of the disqualifier to be 









assigned to that midshipman. A null value aborts the cycle, 
and an invalid entry causes reprompting. Another crucial 
check is made to ensure that an intersection record does not 
already exist for that midshipman and disqualifier code; if 
one does, an error message and reprompt are displayed. Next 
the code, text description, and standard flags for the 
disqualifier are displayed, and the user enters any waiver 
flags for the nine warfare specialties (i.e., AIR_waiver, 
NFO_waiver, etc.). Each input is validated as being WG, LW, 
WR, UE or blank before continuing to the next waiver flag. 
POMS then asks the user to approve entry of the new 
intersection record into the data base and either appends 
the current date or discards all input. 

The preliminary steps in modifying a DISQUALIFIERS 
record are similar to those above. A valid alpha or Social 
Security number yields the name and company number of the 
midshipman. A null code entry aborts the current 
modification process, while an error message and reprompt 
occur if an intersection record cannot be found for the 
given midshipman and disqualifier code. When the 
intersection record is found, the text description of the 
disqualifier, standard flags, and existing waiver flags are 
displayed. The user then inputs the new waiver flags, each 
of which is validated before continuing to the next. After 
confirmation, PQMS modifies the intersection record to 









reflect the new set of waiver flags and current date; 
otherwise, the record left unchanged. 

Deleting a disqualifier is identical to modifying one 
through the point at which the text description, standard 
flags, and old waiver flags are displayed. PQMS then either 
deletes or retains the intersection record, based on the 
user's confirmation input. 

E. GENERATING PHYSICAL QUALIFICATION STATUS REPORTS 

The Generate_Reports menu is the starting point for 
p jducing detailed or summary physical qualification status 
reports. The formats of these reports were presented 
in Figures 1 and 2. Five options are available: 

1. Detailed report on one individual (to CRT screen), 
including adding and deleting comments 

2. Detailed report on one individual (to printer) 

3. Detailed reports on all midshipmen in a given 
company and year group (to printer) 

4. Summary report on all midshipmen in a given company, 
sorted by year group (to printer) 

3. Summary report on all midshipmen in a given year 
group, sorted by company (to printer) 

These are the most demanding activities performed by PQMS, 

in terms of both input/output and processing, and 

consequently the most time-consuming. The sequence of the 

options roughly corresponds to the increasing complexity of 

the underlying processing tasks. 

A detailed report on an individual, either to the CRT 

screen or printer, requires only one user input—a valid 














alpha or Social Security number. Using either of these, 

PQMS locates the midshipman record in the BRIGADE data base 
and displays the personal information contained in that 
file. Using the individual's alpha number, PQMS then 
searches the DISQUALIFIERS file for any related intersection 
records. If none are found, a statement to that effect is 
produced, and the summary flags for all warfare specialty 
default to PQ. Otherwise, PQMS uses the DISQUALIFIERS Code 
field to find the corresponding record in STANDARDS and 
compares the corresponding pairs of flags using the decision 
table of Figure 8 (i.e., AIR_std vs. AIR_waiver, NFO_std 
vs. NFO_waiver, etc.). The code, text description, date of 
the most recent change to the intersection record, and the 
nine status flags for that disqualifier are displayed, and 
the status flags are evaluated using the algorithm for 
summary flags of Figure 9. This process continues for all 
disqual 1 f 1 ers assigned to the midshipman. The nine summary 
flsgs are then displayed in their final form. 

At this point, the procedures for CRT display and 
printing diverge. In both cases, the alpha number is used 
to find all related records in the COMMENTS data base. When 
the detailed report is printed, these are directly output in 
order from the oldest to most recent. Because of the 80 :: 

25 character limitation of a CRT screen, however, output 
pauses after the nine summary flags, and the user is 
prompted to press any key to clear the screen and display 











any comments. This second screen also af-fords the user the 
opportunity to delete old comments or add new ones. No 
error-trapping is used per se. Instead, the comments screen 
is refreshed after each deletion or addition, after which 
the user may correct any errors. 

During the annual precommissioning physical examination 
evolution, midshipmen are usually processed in groups based 
on their company. To facilitate this, POMS provides the 
ability to print detailed reports on all individuals in a 
particular company and year group. The user begins by 
entering the desired company number, then year group. A 
null value for either aborts the process. When valid inputs 
have been entered for both, the reports are printed as 
described previously for individual detailed reports, each 
on a separate page and in alphabetical order. 

To assist the Brigade Officers and Division of 
Professional Development in their career counseling roles 
and in administering the summer cruise and service selection 
programs, PQMS can produce summary physical qualification 
status reports on all midshipmen in a particular company or 
year group. The processing logic for these reports is 
virtually identical. First, the user enters the desired 
company (or year group). As before, the input is validated, 
and a null entry aborts the process. Using the BRIGADE, 

DI3PUALIFIERS, and STANDARDS data bases, PQMS determines the 
warfare specialty summary flags for each midshipman in the 









chosen subset. These are stored in the SUMMARY data 


| structure, along with the midshipman's alpha number, name, 

and sex. These records are then indexed and printed. The 
company report lists each year group on a separate page, 

| while the year group report lists each company on a separate 

page. After either report is printed, the SUMMARY data 
structure is purged, leaving only its shell for use by for 
| the next report, and the index is erased. 

F. PRINTING STANDARDS DATA 

The STANDARDS data base file can be printed in its 


i 


existing farm (see Figure 3) as a reference guide 
updating the FQMS data base or to allow review by 
authority. The procedure is straightforward. The 
simply chooses whether the listing is to be sorted 
or alphabetically. PQMS then uses the appropriate 
produces a printout of all records in STANDARDS in 


for 

an outside 
user 
by code 
index and 
the 


desired order. 












VII. SUMMARY 


A. HARDWARE AND SOFTWARE CONFIGURATION 

Systems design consists of two phases, logical design 
and physical design. So -far, this thesis has only dealt 
with the logical design o-f the Physical Qualification 
Monitoring System, addressing design issues such as outputs, 
inputs, data base files, and procedures. There is nothing 
which precludes imp1ementation of the PQMS logical design on 
MATS or any other Naval Academy computer system. 

Because of the development environment for the POMS, 
however, the system was explicitly designed for 
implementation an a microcomputer. The hardware and 
software selected for the PQMS include: 

- Televideo XL Portable Computer (with RAM expansion to 
512 Kbytes) 

- Xebec 10HB External Hard Disk 
Citizen MSP-10 Dot Matrix Printer 
Microsoft MS-DOS (Version 2.11) 

- dBASE III (Version 1.1) 

KERMIT Communications System 

Actually, once the decision was made to use a microcomputer, 
there was little choice regarding the hardware and software. 
Based on a contract awarded to Federal Data Corporation in 
May 1785, the Televideo XL is now the standard personal 
microcomputer for the Navy and Air Force. Except for KERMIT 



















which is public-domain software, the PQMS configuration is 
based exclusively on that contract. 

Federal procurement contracts are often a mixed 
blessing. This is particularly true of the PQMS. On the 
positive side, the problem of choosing from the growing 
number of microcomputers in today's market was eliminated, 
as were problems stemming from involving multiple vendors 
when building a system. The built-in serial port allows 
direct connection of the Televideo XL to the 2400-baud, 
hard-wired NATS communications lines, and the 10-megabyte 
external hard disk provides sufficient storage capacity for 
the PQMS files. 

Unfortunately, the Televideo lacks a cassette tape or 
similar backup facility, so floppy disks are the primary 
backup medium for the PQMS. Since some of these files 
<e.g., DI3QUALIFIERS, COMMENTS) may exceed the 360-kilobyte 
capacity of a floppy disk, other alternatives are needed. 

As an interim measure, larger files can be backed up to 
MATS, but the long-term solution is a cassette tape backup 
unit. Another potential problem with the Televideo XL is 
speed. This microcomputer uses an Intel 8088 microprocessor 
chip and operates on a 4.77 MHz clock. While these are 
adequate for some applications, the PQMS detailed physical 
qualification status reports involve a large volume of 
input/output and a very heavy processing load, especially if 
the report is on an entire year group. The hard disk helps 















somewhat by speeding up input/output, but the processor 
speed is the main problem. Potential solutions are to 
enhance the Televideo with an accelerator expansion card or 
to upgrade to a -faster microcomputer (e.g., IBM PC-AT, 
Compac DeskPro 286, etc.). 

B. POMS AS AN EXPERT SYSTEM 

Expert systems have received considerable attention in 
recent years and are at the heart o-f what is known as the 
"fifth generation" of computer technology. These systems 
are programs which have the knowledge and capability built 
in to allow them to operate at the expert's level. The two 
principle components of an expert system are a knowledge 
base and inference engine. The knowledge base contains 
both general facts of the problem domain and the heuristic 
or experiential knowledge of one or more experts from that 
field. The inference engine is the reasoning process which 
applies the domain and heuristic knowledge to the situation 
at hand to find an answer or solution. Many inference 
engines are generic in that they can be used with different 
knowledge bases to address problems from a variety of 
domains. CRef. 8:pp. 63-64, 76-791 

The PQMS is not designed as an expert system. Its 
reasoning processes are part of the program and cannot be 
segmented out for general use in other domains. However, 
the system closely mimics an expert system through its 


















ability to make physical qualification determinations using 
stored knowledge, to explain those determinations via its 
detailed reports, and to pass on knowledge -from one 
generation of user to the next. 

C. PQMS AS A PROTOTYPE 

Prototyping is a term long associated with the more 
mature engineering fields. For example, automobile and 
aircraft manufacturers have for years developed prototypes 
to test and refine new design concepts before going into 
full-scale production. Computer hardware engineers have 
also adopted this strategy. Based on a hardware 
requirements analysis, a preliminary configuration is 
designed using off-the-shelf and/or custom-built components. 
This prototype is then tested and modified until all 
requirements are met CRef. 4:p. 91. More recently, software 
engineers have seen the applicabi1ity of such proven 
techniques from the older engineering disciplines to their 
own, and prototyping software is becoming increasingly more 
common■ 

There are a number of reasons for prototyping software 
systems. Sometimes prototypes are warranted because of the 
high cost or high risk inherent in a given project; consider 
the relevance of software prototyping to the Strategic 
Defense Initiative. Certain types of systems <e.g., 
decision support systems) are best developed using 















prototyping because of their lack of structure and 
non-repetitive nature. CRef. 3:p. 63 

PQMS does not fall into either of those categories, but 
there are still compelling reasons for using this approach. 
Although the role of the Branch Clinic in monitoring 
physical qualifications is wel1-understood, those 
information needs are not easily translated into a formal 
requirements specification. Even if they were; prototyping 
is still appropriate in instances where the analysts have no 
prior experience in building such a system CRef. 9:p. 2283. 
This is certainly the case with PQMS. Therefore, the system 
has been designed as a prototype to clarify the information 
requirements of the Branch Clinic and to allow for the lack 
of experience of the analyst/programmer. 

D. EXTENSIONS OF PQMS CONCEPTS 

The PQMS prototypes a highly specialized, site-specific 
application. However, there are at least two possible 
extensions of this system. 

The logical design of the system should be adaptable for 
use by the other service academies. West Point and the Air 
Force Academy also commission their graduates into a variety 
of warfare specialties, each with its own physical 
qualification standards. The Coast Guard Academy sends all 
graduates to sea duty, but still must determine whether they 
are physically qualified for a regular Coast Guard 














commission. Those who are not must accept commissions in 
Coast Guard Reserve. 

Second, the idea of establishing a knowledge base o-f 
physical qualification standards has merit. This knowledge 
base could be distributed to naval medical treatment 
facilities, along with programs to compare an individual's 
physical examination results with those standards. This 
could provide invaluable assistance in those settings where 
the health care provider is not familiar with current 
physical standards or with the waiverabi1ity of certain 
disqualifying conditions. In addition, by building the 
knowledge base separate from the underlying programs, 
updates could be easily compiled and issued to field 
activities, ensuring uniform use of current information 
throughout the Navy. 
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